\newcommand{\yes}{\multicolumn{1}{c}{$\checkmark$}}

\newcommand{\no}{\multicolumn{1}{c}{\texttimes}}

\newcommand{\kinda}{\multicolumn{1}{c}{$\circ$}}

\newcommand{\alc}{\hspace{0.6cm}}
\newcommand{\alcx}{\hspace{0.5cm}}

\section{Discussion and Related Work}
\label{sec:RW}

Since the seminal contributions of Lodderstedt and Basin with Secure\textsc{Uml} \cite{Lodderstedt2002}, and Jan with \textsc{Uml}Sec \cite{Jan2002} back in 2002, model-based development of secure systems has been a very active research area. In Table \ref{table:stateOfTheArt}, we compare several contributions with respect to several dimensions: system (DM) and security modeling (SM); contextual security (CS); security concerns (SC) (i.e. what kind of security properties can be expressed); and code generation (CG). The rest of the section contrasts these approaches with ours. Since runtime policy updating and security rule violation monitoring is not, to the best of our knowledge, present in any of these approaches, we do not discuss this dimension.

\medskip\noindent
\textbf{Domain \& Security Modeling.}  \textsc{Uml} is by far the most represented way for domain security, as witnessed by the first column in Table~\ref{table:stateOfTheArt}. As already reminded, these approaches annotate the business \textsc{Uml} model with security requirements. 

On the other hand, many systems have security requirements way beyond only access control, as Basin, Clavel and Egea already noticed \cite{Basin2011}. However, these requirements are rarely covered by current \textsc{Mds} approaches. Fortunately, some of these requirements can be expressed with obligations, as demonstrated for usage control and privacy policies by several authors \cite{Barth2006,Barth2007,Elrakaiby2011,Mont2004a,Park2004}. To the best of our knowledge, \SAR is the first \textsc{Dsl} that integrates both authorisations and obligations, with management and enforcement support using an \textsc{Mds} approach. There are however other security properties not covered by our approach (information flow, confidentiality) whereas confidentiality can be expressed using access control requirements and are \emph{de facto} supported. It remains to explore the possibility of enriching our \textsc{Dsl} to tackle other concerns. 

\medskip\noindent
\textbf{Contextual Security.}  If some approaches allow the specification of runtime conditions, security rules are usually expressed using a mix of \textsc{Uml} annotations and \textsc{Ocl}-based constraints. However, \textsc{Ocl} can only address limited runtime specifications: for example, expressing the fact that an instance field's value participates in a method call as an effective parameter is not an easy task. Contrasting with these approaches, we handle runtime conditions in a compartimented way: an abstracted representation of the runtime is maintained, and the security officer designs requirements using a pattern-like language for specifying contexts and operations participating in policy actions. The matching, at runtime, ensures a dynamic evaluation of the requirements. 

%\paragraph{Abstraction \& Separation of Concerns} Most MDS works have proposed the use of UML extensions for the specification of security concerns \cite{Jan2002,Basin2006a,Breu2007a}. Using this approach, elements of the design model are annotated with their security requirements. When specification of conditions on the system run-time state is supported, security rules are associated with constraints specified in an OCL(-based) language. Since the annotation of system models and the use of OCL constraints make difficult to see the boundaries between the system and security design languages, we on the other hand make a clearer separation between elements of the design and security models as follows: security requirements are specified using the security modeling language abstractly. Note that runtime state conditions are also abstracted using using {\it contexts}. The security model is then mapped to the system mode using contextual rules which represent the bridge between the security and system models. 



%In our work, policies are specified using the abstract entities of role, action and context. This fulfills the requirement of abstraction, enables policy reuse and simplifies policy specification and interpretation by non-experts. This latter feature is also needed for the communication between the different people involved in the system development process. Reciprocally, the mapping between the security and system models is performed using the {\it contextual rules}. Therefore, it does not require the manipulation of the system model, e.g. annotating the target model. We argue that this provides a good level of separation of concerns.


\medskip\noindent
\textbf{Security Concerns.} Very few approaches can handle several security properties. With \textsc{Uml}Sec, Jan \cite{Jan2002} supports confidentiality, information flow and access control. ModelSec \cite{sanchez_modelsec} seems promising: the \textsc{Dsl} at the core of the language can easily be extended with new security concerns.

\medskip\noindent
\textbf{Code Generation.} Despite the use of \textsc{Mds} techniques, using automated transformations, it is still difficult to enable full code generation from high-level requirements. Secure\textsc{Uml} \cite{Basin2006a} supports the generation of secure systems for two target architectures (Enterprise JavaBeans and Microsoft DotNet), but the generating mechanism relies on pre-existing security mechanisms. In \textsc{Sectet}, the information relevant for authorisations are specified using the tool's language, and transformed into \textsc{Xacml} specifications. In \cite{sanchez_modelsec}, security and business are composed into a model from which Java code is generated. In our approach, code generation appears in two areas: first, aspects are automatically generated and tailored for the application on the basis of the static mappings; and second, security policies are generated from the security model into Prolog, to compute policy decisions. 

%
%The secureUML \cite{Basin2006a} approach supports the generation of secure systems for two target architectures, namely Enterprise JavaBeans and Microsoft .Net. The approach capitalizes on the existing security mechanisms of the target architecture, i.e. no particular security architecture is generated but existing mechanisms in the target architecture are used. In SECTET \cite{Breu2007a}, authorization-relevant information specified using the SECTET-PL language is transformed to a XACML policy specification. In \cite{Moebius2009}, the system and security are composed and Java code is generated from the composed model. In our work, code-generation is two-folded: on one hand, aspects needed to monitor/control the target according to the static mapping rules are automatically generated. On the other hand, security policies are generated from the security model. Note that we have implemented an application-independent policy independent in order to enforce our security policies. This is contrasted with the other approaches which capitalize on existing solutions, e.g. XACML policies in \cite{Breu2007a}. The main motivation behind our choice is to support obligation policies whose management is currently not supported\footnote{Although it is possible to specify obligation policies in XACML, their management is not supported.}. 

\begin{table*}[t]

%\begin{tabularx}{p{1.5cm} p{1.5cm} p{1.5cm} p{1.5cm} p{1.5cm} p{1.5cm} p{1.5cm} p{1.5cm} p{1.5cm}}
\begin{tabularx}{\textwidth}{X X X X X X} % 6 columns

\toprule 


%{\bf } &  \alc{ {\bf FPL}} & \alc{{\bf PU}} & \alc{{\bf PP}} & \alc{{\bf SRC}}& \alc{{\bf OS}} & \alc{{\bf RS}} & \alc{{\bf PS}} & \alc{{\bf CR}} \\ 

 &  \alcx{\bf DM} &  \alc{\bf SM} & \alc{\bf CS} &\alc {\bf SC} & \alc{\bf CG} \\ 

\midrule 

{\bf SecureUML}\cite{Basin2006a}&\cc{UML}&\cc{Profiles}&\cc{OCL}&\cc{AC}&\yes\\
{\bf UMLsec}\cite{Jan2002} & \cc{UML}&\cc{Profiles}&\no&\cc{C,IF,AC}&\no\\
{\bf secureMDD}\cite{moebius_securemdd:_2009}& \cc{UML} & \cc{Profiles} &\no & \cc{AC}&\yes \\
{\bf ModelSec}\cite{sanchez_modelsec}& \cc{UML} & \cc{SecML}&\kinda & \cc{MC}&\yes\\
 {\bf SECTET}\cite{Breu2007a}& \cc{SE-UML} & \cc{Profiles}&\cc{SE-PL}&\cc{AC}&\kinda\\
{\bf S@R }& \cc{UML}&\cc{S@R} & \cc{S@R}&\cc{AC,OB}&\yes\\

\midrule
\multicolumn{6}{c}{AC: Access Control, C: Confidentiality, }\\
\multicolumn{6}{c}{ IF: Information Flow, OB: Obligations, MC: Multiple Concerns}\\

\midrule

\multicolumn{6}{c}{ {\bf DM}: System Modeling, {\bf SM}: Security Modeling, {\bf CL}: Contextual Security}\\

\multicolumn{6}{c}{  {\bf SC}: Security Concerns, {\bf CG}: Code Generation} \\
%\multicolumn{9}{c}{ }\\

\bottomrule 

%\textit{•}
\end{tabularx} 

\vspace{0.5cm}
\caption{Comparison of \SAR with Existing MDS approaches}
\label{table:stateOfTheArt}

\end{table*}

%\comments{
%SECETET \cite{Breu2007a} study the security of service-oriented services.
%
%ModelSec \cite{sanchez_modelsec:_2009}
%
%UMLsec \cite{Jan2002}
%
%secureUML \cite{Basin2006a}
%
%secureMDD \cite{Moebius2009}
%}